---
title: Running multiple instances
description: Configure multiple instances from a single bud.js config.
---

:::info Experimental

This is a newer feature of bud.js. It is possible that this API will change in future releases. We suspect these changes will
be driven by the needs of users.

:::

It is possible to configure more than one compilation in a project.

For a single page app this isn't really that useful. However, for WordPress or a Symfony app &mdash; or anything with
different build requirements for different application components &mdash; it is potentially very useful.

## Creating child instances

To create a new child instance, we can use [bud.make](/reference/bud.make).

The simplest implementation sets the `label` of the compiler with a `string`, and provides a configuration callback:

```ts title=bud.config.js
export default async bud => {
  await bud.make('theme', async theme => theme.entry('index'))
}
```

More complex implementations can be achieved by supplying **context** overrides using an object:

```ts title=bud.config.js
export default async bud => {
  await bud.make(
    {label: `plugin`, basedir: bud.path(`plugin`)},
    async plugin => plugin.entry(`index`),
  )
}
```

See the [bud.make](/reference/bud.make) documentation for more information.

## Using the `--filter` flag

The other benefit is a potentially massive workflow improvement. Let's say that we have to work on the `theme` more often than the `plugin`.
With the above config we don't have to rebuild the `plugin` code again just to work on our `theme` code.

We can use the `bud` cli to only run the compiler we need using [the `--filter` flag](/learn/cli/build).

```sh
$ yarn bud build --filter theme
```

If you had more than two instances it might make sense to want to target more than one compiler, and `--filter` supports that:

```sh
$ yarn bud build --filter theme --filter plugin
```

## Configuring unique extensions per compiler

By default, all extensions will be applied to all compilers in the project.

If the extensions differ between compilers you can either use the `--no-discovery` flag or set the
[`bud.extensions.discovery` property in your root package.json to `false`](/learn/config/files/package)
to prevent extensions from being automatically injected.

Then, you can manually load the extensions on a per-compiler basis:

```ts title=bud.config.js
export default async bud => {
  await bud.make('theme', async theme => {
    theme
      .use('@roots/bud-postcss')
      .setPath('@dist', 'dist/theme')
      .entry('theme', ['theme.css'])
  })

  await bud.make('plugin', async plugin => {
    plugin
      .use('@roots/bud-react')
      .setPath('@dist', 'dist/plugin')
      .entry('plugin', ['plugin.js'])
  })
}
```

## Configuring the development server

Any configuration of the development server should be done in the parent context.

This includes:

- [bud.serve](/reference/bud.serve)
- [bud.proxy](/reference/bud.proxy)
- [bud.watch](/reference/bud.watch)

```ts title=bud.config.js
export default async bud => {
  /**
   * Configure dev server in the parent context
   */
  bud
    .watch([`resources/views/**/*`, `app/**/*`])
    .proxy(`https://sage.test`)
    .serve(`http://0.0.0.0:3000`)

  await bud.make(`app`, async app => app)
  await bud.make(`editor`, async editor => editor)
}
```

Child instances do not feature their own development server. This is incorrect:

```ts title=bud.config.js
export default async bud => {
  await bud.make(`app`, async app => {
    app
      .watch([`resources/views/**/*`, `app/**/*`])
      .proxy(`https://sage.test`)
      .serve(`http://0.0.0.0:3000`)
  })

  await bud.make(`editor`, async editor => editor)
}
```
